SecurityGroup を削除する時に気をつけているアレやコレや
不要になった SecurityGroup（以下 SG） を削除する時、結構気を遣いませんか？
- これ本当に削除して大丈夫なの？
- リカバリすることになったらどうする？
こんなことが脳裏によぎり、私はいつもドキドキしながらやっています。そのドキドキを少しでも減らすために事前確認や準備していることを書きたいと思います。実際にどこまで実施するかは、状況に応じて異なるため全部やることが正しいわけでもなく不足している部分もあるかと思います。あー、そんな視点や方法もあるね。と気付きがあれば幸いです。
※ 重要なお願い事項 ※
是非、そもそもドキドキするような管理方法や対応しているのが...というツッコミはなさらずに、ご覧になってください。
事前確認編
インバウンド / アウトバウンド ルールチェック
まずは対象 SG がどのような用途なのか、どんな通信が許可されているかを確認します。
- EC2 > セキュリティグループ >
セキュリティグループ ID: sg-*****
===== 余談１ =====
ここで セキュリティグループ ID を指定したのは、指定せずに検索を行うと対象 SG をソースとして設定している SG も結果表示されるためです。例では２つなので視覚的にわかりますがこれが大量になるとオペミスにもつながる可能性があります。（ CLI でチェックするのがお勧めですが見やすさはマネジメントコンソールが良い）
===== 余談完 =====
セキュリティグループ名や ID から対象 SG に誤りがないことや 説明 に用途を類推出来るものがないかを見ます。説明と実態が必ずしも一致はしないので参考程度にします。
- インバウンドルール タブ を見ていきます。ここではまず 説明 を確認します。例では記載があるものないものが混在しており、記載がないものは ソース などの他項目を見ても用途を判別することは難しいです。
- アウトバウンドルール タブも見ていきます。アウトバウンドは制限せず、例のような設定が多いのではないかでしょうか。
- タグ タブも手がかりとなり得ます。
こういった状況では、大半は不明瞭なルールに対して、これってなに用途？削除していいの？といった具合に棚卸しが始まります。。例えば以下のような方法が想定されます。
- （別途 IP アドレスリストや通信管理表などを保有している場合）構成管理情報から確認
- 過去対応履歴から確認
- （グルーバル IP アドレスの場合は）アカウント内の Elastic IP として取得しているものか？を確認
- （プライベート IP アドレスの場合は） VPC Cidr や VPC Peering や Direct Connect などの内部通信設定を確認
ここで改めて気づくのは 各ルールの 説明 への記録の重要性です。 これがあるとないでは、確認の容易さが変わってきます。手間ではありますがルール設定する際には、記載することを習慣付けておくと後々自分たちを助けてくれます！
結果判定
用途が明確に把握が出来き、不要と判断出来る場合には、粛々と後続作業を進めます。
一生懸命調べたけど、わからん。。という場合には以下のどちらかを取ります。
- SG は残したまま インバウンド・アウトバウンドルールを削除して影響が出るかを判断する（すぐにリカバリ出来る準備はしておく）
- 通信と経路をキャプチャ出来るサービスやツールを用いて可視化を行う
利用リソース確認（ SG 単位）
良い場合も悪い場合も、対象 SG の設定状況が把握出来たら続いては、その SG をアクセス制御として利用している EC2 や ELB、ENI などの AWS リソースを確認していきます。ネタバレになりますが、いきなり SG を削除しようとすると以下のようなメッセージが表示されます。
上記メッセージで 理由 のリンクを選択することで利用リソースをフィルタリングした状態で表示することも出来ますが、ここでは情報を出力することも念頭に入れて、別方法で進めていきます。
方法としては２つあります。それぞれ弊社メンバーが記事にしてくれています！
- ENI 編
- AWS Config 編
今回は、AWS Config を利用したパターンで行っていきます。 下記コマンドを実行するとアタッチされている AWS リソースが出力されます。
$ aws configservice get-resource-config-history --resource-type AWS::EC2::SecurityGroup --resource-id sg-010e489d18a055bd1 --max-items 1 --query 'configurationItems[].relationships' --output table ------------------------------------------------------------------------------------------------ | GetResourceConfigHistory | +-------------------------------------+-------------------------+------------------------------+ | relationshipName | resourceId | resourceType | +-------------------------------------+-------------------------+------------------------------+ | Is associated with NetworkInterface| eni-0baf9a3843ba262e0 | AWS::EC2::NetworkInterface | | Is associated with NetworkInterface| eni-0aa6e66d3261870a5 | AWS::EC2::NetworkInterface | | Is associated with NetworkInterface| eni-082b5f90e95a8c4ed | AWS::EC2::NetworkInterface | | Is associated with NetworkInterface| eni-04bd7aac24d955642 | AWS::EC2::NetworkInterface | | Is associated with NetworkInterface| eni-08d3f8b691e7869b2 | AWS::EC2::NetworkInterface | | Is contained in Vpc | vpc-086b69234313bbb0e | AWS::EC2::VPC | +-------------------------------------+-------------------------+------------------------------+
===== 余談２ =====
昨年の夏頃に AWS より 上記で利用した AWS Config Relationship に関する変更の案内がありました。（通知だけでサイトなどの公開情報を確認することが出来なかったため、今後変更も想定されるため、詳細な内容は割愛します）上記の方法で SG から間接関係にあたる EC2 や ENI の情報を検索することが非推奨となるといった内容です。
代替方法としては同じ AWS Config にある 高度なクエリ による検索となります。今からこちらに切り替えておく方が良いかもしれません。
マネジメントコンソール
CLI
$ aws configservice select-resource-config --expression "SELECT resourceId,resourceType WHERE relationships.resourceId = 'sg-010e489d18a055bd1'" --output table
------------------------------------------------------------------------------------------------
| SelectResourceConfig |
+----------------------------------------------------------------------------------------------+
|| QueryInfo ||
|+--------------------------------------------------------------------------------------------+|
||| SelectFields |||
||+------------------------------------------------------------------------------------------+||
||| Name |||
||+------------------------------------------------------------------------------------------+||
||| resourceId |||
||| resourceType |||
||+------------------------------------------------------------------------------------------+||
|| Results ||
|+--------------------------------------------------------------------------------------------+|
|| {"resourceId":"blog-delete-sg","resourceType":"AWS::ElasticLoadBalancing::LoadBalancer"} ||
|| {"resourceId":"eni-04bd7aac24d955642","resourceType":"AWS::EC2::NetworkInterface"} ||
|| {"resourceId":"eni-082b5f90e95a8c4ed","resourceType":"AWS::EC2::NetworkInterface"} ||
|| {"resourceId":"eni-08d3f8b691e7869b2","resourceType":"AWS::EC2::NetworkInterface"} ||
|| {"resourceId":"eni-0aa6e66d3261870a5","resourceType":"AWS::EC2::NetworkInterface"} ||
|| {"resourceId":"eni-0baf9a3843ba262e0","resourceType":"AWS::EC2::NetworkInterface"} ||
|| {"resourceId":"i-04ca6aad5f4916465","resourceType":"AWS::EC2::Instance"} ||
|| {"resourceId":"i-090e8e7693e898744","resourceType":"AWS::EC2::Instance"} ||
|| {"resourceId":"vpc-086b69234313bbb0e","resourceType":"AWS::EC2::VPC"} ||
|+--------------------------------------------------------------------------------------------+|
===== 余談完 =====
５つの ENI にアタッチされています。上記の情報から ELB と EC2 周りを確認することで、個々のリソースを特定することが出来そうです。実際、記事用に用意したのは下記のリソースとなります。
- EC2（ENI:1） x2
- ELB（ENI:2） x1
- ENI:1 *1
SG を複数アタッチしているケースも多いため、ここで想定した以外リソースには対象 SG がアタッチされていないかを確認することも重要です。
結果判定
これで、対象 SG のルールとリソースが把握でき、影響があるサービスが明確になってきます。認識に齟齬がなければ、後続作業を進めます。
利用リソース確認（ルール単位）
上記以外にも、余談１で紹介したソースとして利用しているケースがあります。ここも確認しておきます。
マネジメントコンソール
- EC2 > セキュリティグループ >
ソース/送信先 (グループ ID): sg-******
CLI（ query で情報を限定）
$ aws ec2 describe-security-groups --filters Name=ip-permission.group-id,Values=sg-010e489d18a055bd1 --query "SecurityGroups[*].{Name:GroupName,ID:GroupId}" --output table
----------------------------------
| DescribeSecurityGroups |
+------------------------+-------+
| ID | Name |
+------------------------+-------+
| sg-039ffc550552dd2a6 | test |
+------------------------+-------+
$ aws ec2 describe-security-groups --filters Name=egress.ip-permission.group-id,Values=sg-010e489d18a055bd1 --query "SecurityGroups[*].{Name:GroupName,ID:GroupId}" --output table
$
結果判定
削除対象 SG はソースとして設定されていることがわかりました。設定している SG をアタッチしているリソース（ EC2 や ELB ）において、そのルールを削除しても問題ないかを事前に確認する必要があります。
===== 余談３ =====
上記で記載したルール利用状況を確認する条件としては他にも IP アドレスなどが可能です。特定グルーバルIPアドレスが変更・不要となった際に関連するリソースを洗い出す際にも有効です。
$ aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=8.8.8.8/32 --query "SecurityGroups[*].{Name:GroupName,ID:GroupId}"
AWS CLI Command Reference - describe-security-groups
===== 余談完 =====
ここまでで、３つの視点で確認を行いました。
もし想定外の状況が続いているのであれば 削除ではなく整理をする目的に一度切り替える 方が良いかもしれません。
事前準備編
実際の削除方法はケースバイケースなので、ここでは 「あ！これ削除しちゃだめだった！！」と阿鼻叫喚なシチュエーションに対する準備として、バックアップして SG の再作成やルール設定を可能とする準備を取り上げます。
対象 SG バックアップ
既存設定を CLI に出力し、それを元に再作成なども想定出来ますが、可能であれば SG のコピーがシンプルかつ容易です。
- EC2 > セキュリティグループ > アクション > 新しいセキュリティグループにコピー
インバウンドを始め、各種設定を引き継いだまま作成が可能です。（ 名称や ID が変更されますが、この場合は小事ではないかと思います）
名称や説明に temp や backup など、その用途が明らかになるようにしておきます。作成された セキュリティグループから ID を控えておきます。
利用リソースへの再設定
バックアップとして作成した セキュリティグループ ID と事前確認で情報（利用している AWS リソースやソースルール）からスムーズに再現する手段を用意します。 件数にもよりますが個人的には CLI やツールなどを利用する方が、いざという時の負担・リスクは低くなるかと思います。
EC2 へのアタッチ
ルール追加
いざ、削除編
最後は削除となります。それぞれ状況下で方法は多様にあるかと思いますので、今回は対象外とします。また状況によっては、用途がわからずリスクが残っている場合に、まずはルールを削除して様子を見て、サービスに影響がなければ SG を削除といった段階を踏むケースもあるかと思います。
マネジメントコンソールから手動でも CLI でも、ツールを活用するのも良いかと思います。準備がしっかり出来ていればドキドキも少しは減り、あとは効率と証跡を基準に作業するのみです。（リカバリが発生しないことをただただ祈りながら...）
さいごに
今回は、SG を削除する際に、ケアしている部分をアレやコレやと書いていきました！どなたかのお役にたてれば幸いです。
